Web-based game platform with mobile device motion sensor input

ABSTRACT

A distributed gaming platform is provided wherein mobile devices (e.g., a smartphone) with motion sensors are used as input controllers of a game. A cloud-based gaming rules engine manages multiple players and the content for display in the game. The game output is displayed on any web-enabled display which is physically distinct from the mobile device. Multiple players may simultaneously play the same game, or different games, in multiple geographic locations.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of Ser. No. 13/875,179, filed May 1,2013, pending, which claims the benefit of provisional Ser. No.61/641,825 to Jeffery et al., filed May 2, 2012, the subject matter ofwhich is incorporated herein by reference. This application is alsorelated to U.S. patent application Ser. No. 13/269,534 to Jeffery, filedOct. 7, 2011, and entitled “METHOD AND SYSTEM FOR DYNAMIC ASSEMBLY OFMULTIMEDIA PRESENTATION THREADS”; U.S. application Ser. No. 13/655,366to Jeffery et al., entitled METHOD AND SYSTEM TO ANALYZE SPORTS MOTIONSUSING MOTION SENSORS OF A MOBILE DEVICE, filed Oct. 18, 2012; and U.S.application Ser. No. 13/659,774 to Jeffery et al., entitled METHOD TOPROVIDE DYNAMIC CUSTOMIZED SPORTS INSTRUCTION RESPONSIVE TO MOTION OF AMOBILE DEVICE, filed Oct. 24, 2012; the subject matter of eachincorporated by reference herein in its entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to the field of computer games, and moreparticularly, to a distributed web-based game platform with mobiledevice motion sensor input.

2. Description of the Related Art

There is extensive prior art in video gaming, dating back to the firstgame of Pong in 1972, where with a very simple controller users hit a“ball” game of Pong in 1972, where with a very simple controller usershit a “ball” (a dot on the screen) back and forth with “paddles” (twoshort lines sliding up and down) on a monochrome screen. Controllers andgaming consoles have advanced considerably in the last 40 years. ThePlayStation Move, for example, has customized controllers for golf(Tiger Woods Golf) and tennis (Grand Slam Tennis), or fighting (TheFight), where the gaming console costs approximately $250 and customizedcontrollers an additional $70. The Move controller, for example, uses acamera and captures motion via a Bluetooth controller with infraredlight sensors. The Xbox 360 Kinect does not even use a physicalcontroller, as player body motions are captured via three, 3-D camerasand sophisticated pattern recognition algorithms. The Wii, PlayStation,and Xbox 360 have network capability so as to enable multiplayer gamingthrough their hosted online networks.

Many personal-computer-based games use a keyboard and/or mouse of acomputer as the controller. In World of Warcraft, for example, by usingthe keyboard for communication, users click their character andon-screen functions to control the motions of soldiers as they move,battle, and build. In Gameloft Let's Golf 3 and World PGA Tour Golf,players click a “sliding bar” to control the swing of an avatar golfcharacter. Although these games dispense with the need to purchasecostly controllers, they can be difficult to control using a keyboardand/or a mouse. This is particularly apparent in high-skill games suchas golf where an optimal swing to hit the ball requires amultidimensional body motion combining an arm swing, hip and shoulderturn, wrist hinge, hip shift, forearm rotation and inside out swingpath, each of which done incorrectly results in a less than optimalshot. Indeed, it is simply not possible to simulate the full dynamics ofa golf swing using a keyboard and/or a mouse.

The Nintendo Wii controller is connected via a Bluetooth connection tothe gaming console and senses acceleration in three axes using anADXL330 accelerometer. The Wii remote also features a PixArt opticalsensor, which in combination with a 10 LED Sensor Bar, physicallyconnected to the game console, allows the determination of where the WiiRemote is pointing. A Taiwanese company, ASRock, claims to use iPhonemotion sensors to mimic the controller for a Nintendo Wii game, so thatusers can play existing Wii or PC-based games using an iPhone as a gamecontroller. The iPhone is connected using Bluetooth or a WiFi network tothe gaming console. This reduces the cost of the controller, but usersstill need the game console or a specific game controller hardwaremotherboard in their personal computer. ASRock software installation isalso challenging and there are some usability issues.

Note that the Nintendo Wii controller, or simulated ASRock Wiicontroller using an iPhone, provides data that is not an accuraterepresentation of many sport motions, such as a golf swing, a baseballswing or a tennis serve. That is, the Wii controller can provide onlygross approximations to many sports motions. For example, it can senseif you made a golf swinging motion, and approximately how hard youswung, but the method cannot accurately calculate the speed at impact orthe precise angle of the club head through impact.

US Published Patent Application 2010/0069158 to Kim discloses a methodfor multi-player card and board games such as Korean Hwatu and Mah-Jongwith mobile phones, a gaming server, and a gaming console connected to adisplay device. However, Kim explicitly requires a gaming consolephysically wired to the display device, has simple key data input (ASCIIdata) from the mobile devices not suitable for use for realistic controlof sports games, such as golf, and the mobile phones must be connectedto the gaming console (e.g., via Bluetooth, infrared or a wireless LANconnection).

U.S. Pat. No. 8,019,878 to Allen et al. describes a method to control aweb browser on a local area network (LAN) with a mobile device in orderto create a game. However, the method is limited to devices connected onthe same LAN and requires direct connection of the mobile device withthe web browser on the LAN and a plug-in software download to the webbrowser, which does not work in currently available web-enabled TVs.

There are significant limitations in the video gaming prior art. In thecase of the console-based games, the total cost of ownership to the useris significant (at least $250 for the platform to support a single game,with individual games costing about $70 each and controllers costing anadditional $70). Perhaps this is one reason that sales for console-basedgames have been stagnant for several years. For PC-, tablet- or mobilephone-based games, typical user input is via a computer keyboard ortouch screen, and this interface is not optimal for gaming involvingsports body motions, such as golf, baseball, bowling or tennis.

SUMMARY OF THE INVENTION

According to the systems and methods of the present invention, adistributed gaming platform is provided wherein mobile devices withmotion sensors are used as input controllers of a game. A cloud-basedgaming server managers multiple players and the content for display inthe game. The game output is displayed on any web-enabled display whichis physically distinct from the mobile device. Multiple players maysimultaneously play the same game, or different games, in multiplegeographic locations.

A notable feature of the present invention is that each user establishestwo separate, simultaneous Internet connections: one from the user'smobile device to a cloud-based gaming rules engine, and the other fromthe web-enabled display to the gaming rules engine. While not required,there may also be a connection from the mobile device directly to thedisplay device, if the mobile device and the display device are on thesame wireless local area network (LAN). This optional connection has theadvantage of reducing latency to the user and display device. That is,where the display device is on the same local area network (LAN) withthe mobile device, directly passing of swing data to the display devicevia the LAN is faster than sending the data out via multiple routers toa remote server and then back via multiple routers to the displaydevice.

Furthermore, a distributed architecture is employed with three levels ofcomputation processing: body motions are analyzed using the processor ofthe mobile device, the cloud based gaming rules engine manages multipleplayers, analyzes player interactions, stores and analyzes player motionhistories, and pushes (or allows pulling of) gaming content to eachdisplay device, and the display device itself processes local gaminglogic and renders animations using a light-weight gaming logic pushedfrom the cloud-based gaming rules engine.

There are at least three significant advantages of the present approach:

No additional equipment is necessary. By 2015, there will be over onebillion smartphones worldwide, and all these new phones will have motionsensors. The system disclosed herein is significantly less costly than aconventional gaming console, and in the near future, the average userwill have all the necessary equipment: a mobile device with motionsensors and a web-enabled display.

A computer keyboard, mouse, or touch screen is not needed to control thegame. The keyboard approach is particularly unrealistic for sportsmotion games such as golf, baseball or tennis. For golf, tennis orbaseball, for example, there is a significantly more real worldexperience swinging a phone to hit a virtual ball displayed on a Webenabled TV, instead of hitting a key on a keyboard or clicking a mouse.Furthermore, Wii game controllers and video based body motion captureare not particularly accurate, and do not currently enable preciseanalysis of a golf swing, for example, just gross movement.

Gaming consoles, such as a Wii or Xbox, enable rich graphic rendering ofthree-dimensional objects and have the equivalent computing power of ahigh-performance supercomputer, such as a Cray Y-MP, of the 1990's. Thedisclosed system enables multiplayer simultaneous gaming in multiplegeographically disperse locations without purchasing a gaming console orpersonal computer with a high performance graphics processor. Thedisclosed games are specifically designed to work on any web-enableddevice, with relatively low computing power, and have rich graphicscontent that is actually an enhancement to some console games, such asTiger Woods PGA Golf.

Furthermore, to implement the disclosed web-based distributed gamingplatform at least five significant technical innovations are utilized:

(1) a method for accurately capturing raw motion data from mobile devicesensors, analyzing these data on the mobile device, and transmitting theanalyzed data in a form that enables a low latency connection;

(2) a method to systematically reduce the bandwidth and latency of thegaming display media, sent from the gaming rules engine to the webenabled display device, and for queuing content for caching at theweb-enabled display so as to minimize bandwidth utilization and latency;

(3) a method to enhance the gaming display media for specific displaydevices so as to simulate the real world, while optimizing for thebandwidth and resolution of the display device;

(4) a method for the distribution of computations such that the mobiledevice, gaming rules engine, and web-enabled display optimally analyzegaming motions, multi-players, gaming rules, and respective outputdisplay animations in a distributed processing architecture; and

(5) a method for the gaming rules engine and display device to detectuser inputs that can use either periodic polling of a user database oran event-driven architecture, wherein the mobile devices publish swingevents, and the gaming engine and display device subscribes to specificevents for specific users.

These and other aspects, features, and advantages of the presentinvention will become apparent from the following detailed descriptionof preferred embodiments, which is to be read in connection with theaccompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates various types of rotational movement of a mobiledevice;

FIG. 2 illustrates an exemplary architecture for a multi-playerdistributed gaming platform, according to an embodiment of the presentinvention;

FIG. 3 illustrates an exemplary embodiment of the multi-player gamingplatform architecture, according to an embodiment of the presentinvention;

FIGS. 4( a) to (e) illustrate various user experiences in a preferredembodiment of a golf game of the present invention;

FIG. 5 illustrates an exemplary embodiment of the multi-player gamingplatform for a golf game, according to an embodiment of the presentinvention;

FIGS. 6( a) and (b) illustrate golf hole partitioning into segmentscorresponding to digital images, according to an embodiment of thepresent invention;

FIGS. 7( a) and (b) illustrate the pitch and roll of the mobile deviceduring an example full golf swing useful for determining swing accuracy;

FIGS. 8 (a) and (b) illustrate use of pitch data of the mobile device todetermine the impact point and the speed of the golf club head throughthe impact point;

FIGS. 9( a) and (b) illustrate use of pitch and yaw of the mobile deviceduring an example full golf swing to determine the impact point;

FIG. 10 illustrates the use of layers, cinemagraph, and/or spriteanimations to enhance realism of a digital image, according to anembodiment of the present invention;

FIGS. 11( a) to (c) illustrate changes in pitch, yaw and roll of themobile device during an example tennis swing or seated horizontal golfswing;

FIGS. 12( a) to (c) illustrate yaw, roll and pitch for a baseball swing;and

FIGS. 13( a) to (c) illustrate pitch, roll and yaw for a bowling motion.

DETAILED DESCRIPTION OF THE INVENTION

As used herein, a mobile device refers to a hand-held device having amicroprocessor, memory, and integrated motion sensors. Examples of suchmobile devices include the Apple iPhone, Apple iPod and Samsung Galaxysmartphone. It is to be understood that such mobile devices mentionedherein are meant for illustrative purposes only.

As used herein, a display device refers any Internet connected displaycapable of graphically displaying a Web page.

As used herein, an image refers to any visually perceptible graphicalelement including, but not limited to, a photograph, a sprite, acinemagraph, a video, a raster or vector image, an animation, and othergraphics-engine generated visual objects, and combinations thereof.

As used herein, bandwidth utilization refers to the amount of data thatcan be passed along a communications channel in a given period of time.

As used herein, latency refers to the time delay between transmissionand receipt of data.

As used herein, calibration point refers to the location in time andspace of the mobile device in a set-up position prior to the start of asports motion.

As used herein, impact point refers to the location in time and space ofimpact with a virtual object.

As used herein, release point refers to the location in time and spaceof the release of a virtual object.

In some sports, such as golf, the impact point and release point may bethe same physical location in time and space. However, in other sportsthe impact point and release point may not coincide. For example, inlacrosse the ball is caught by a long-handled stick (the ball impactsthe lacrosse stick at the impact point) and then is later thrown fromthe stick from a different location (at the release point). Furthermore,in some sports there is only a release point since there is not a pointof impact. For example, in fly fishing the release point occurs by aflick of the wrist imparting angular momentum to the fishing rod, whichabove a certain maximum value causes the weighted fishhook to releasefrom the rod.

FIG. 1 illustrates various types of rotational movement measured by themotion sensors of a mobile device 10. These sensors include anaccelerometer to capture X, Y and Z acceleration data (expressed in G'salong a respective axis), and a gyroscope to measure pitch, roll and yawof the mobile device 10 as it moves (expressed in radians with respectto a respective axis). At present, the motion sensors sample at about100 times per second (100 hertz), with this data made available (byeither polling or having the data pushed) to an application loaded onthe mobile device 10. A representative gyroscope useable in conjunctionwith the present invention is the L3G4200D gyroscope made bySTMicroelectronics, Inc. However, it is to be understood that thepresent invention is not limited to motion sensor technology currentlyavailable.

FIG. 2 illustrates an exemplary architecture of a gaming platform 100,according to an embodiment of the present invention. As shown, the threemajor components of the gaming platform 100 are the mobile devices 10, agaming server 110, and display devices 20. The gaming server 110includes a gaming rules engine 115 that manages a plurality of gamesbeing played. As shown, the gaming rules engine 115 has access to a userdatabase 116, a gaming resources database 117, and a motion archivedatabase 118. The user database 116 stores login information and gameinformation. For golf, the game information can include swing data foreach swing made during the game, the player's current score, currentgolf hole number, current selected golf club, etc. The gaming resourcesdatabase 117 can include graphical content for simulating the game onthe display device 20. For instance, for golf, the gaming resourcesdatabase 117 can include a plurality of 2-D images or videos of portionsof each the golf holes indexed such that images can be retrieved basedon which segment of a golf hole the virtual golf ball is projected toland. As will be described in greater detail, the gaming resourcesdatabase 117 can also include various other graphical elements (such ascinemagraphs, videos and sprites) to enhance the gaming experience. Themotion archive database 118 includes historical motion data forlong-term analysis, e.g., for golf, data on swing motion accuracy forlongitudinal comparisons of swing, putting and chipping consistencyimprovement.

In the illustrated embodiment, the gaming server 110 is cloud-basedenabling global connectivity via the Internet 150. For each user, theuser's mobile device 10 and display device 20 can be simultaneouslyconnected to the gaming server 110 through separate and distinctInternet connections. The mobile device 10 transmits data, includinganalyzed motion data to the gaming server 110; in turn, the gamingserver 110, facilitates display of gaming media at the display 20through a separate Internet connection. In an embodiment, a light weightgaming logic engine 120, in the form of a software application, can bepushed to a suitable Web-enabled display device 20 where a substantialamount of the logic of the gaming rules engine 115 is encoded, and thegaming logic engine 120 can then perform much of the work otherwise tobe performed directly at the gaming server 110.

In an embodiment, a user's mobile device 10 and display device 20 can beoptionally connected, depicted by the dashed line 75 in FIG. 2, via alocal area network (LAN) on the same network. The LAN connection enablesvery low latency between motions and gaming animation displays for usersin the same geographic location. In this embodiment, the motion datapasses directly from the mobile device 10 to the display device 20 andto the gaming server 110 in order to enable multiplayer gaming indifferent geographic locations (not on the same physical LAN). Motiondata is transmitted from each mobile device 10 to the gaming server 110via the Internet 150, where it is used to update the display devices 10and/or 20 of the other players in the game. The LAN connection 75enables very fast (millisecond) passing of data to a display device 20on the same LAN as the mobile device 10, speeding up the game play forthat particular player. So, for example, swinging the mobile device 10will result in the appearance of a nearly instantaneous ball flight onthe display device 20 when both are connected on the same LAN, versus anappreciable (e.g., third of a second) delay for data transmitted to thegaming logic server and then forwarded to the display device 20 via anon-local connection.

Where the display device is a personal computer (PC), web-enabled TV,tablet, or similar computing device, a connection can be accomplished byinstalling a suitable web browser plug-in. Preferably, the user will berequired to click a “consent button” to install the plug-in and enablesearching the LAN for a mobile device 10 and communicate with the device10. Alternately, the program could be a custom web browser configured to“listen” to the local network, so that the plug in is effectivelybuilt-in. Current iPad, Android, and Web TV web browsers do not supportplug-in functionality; however it is anticipated that in the near futuresome of these devices will become more open platforms and enable similarconnections. For the iPad and Android platforms, custom apps can bewritten that are essentially skins around a web browser with the plug-inincorporated. Hence, a direct LAN connection to a mobile device 10 canbe made to a multitude of web enabled display device platforms.

FIG. 3 illustrates an exemplary embodiment of the multi-player gamingplatform architecture, according to an embodiment of the presentinvention. The mobile device 10 and the web display device 20 can be inthe same geographical location or in different locations. Thecommunication between the mobile device 10 and the web display device 20takes place via the use of long polling, such as a WebSocket. As shown,two different long polling connections 180 are established between themobile device 10 and the gaming server 110, and the gaming server 110and the display device 20. The gaming server 110 employs a plurality ofpolling ports 130 so as to support a plurality of users and displaydevices.

In the following description of the present invention, exemplary methodsfor performing various aspects of the present invention are disclosed.It is to be understood that the methods and systems of the presentinvention disclosed herein can be realized by executing computer programcode written in a variety of suitable programming languages, such as C,C++, C#, Objective-C, Visual Basic, and Java. It is to be understoodthat in some embodiments, substantial portions of the application logicmay be performed on the display device using, for example, the AJAX(Asynchronous JavaScript and XML) paradigm to create an asynchronous webapplication. Furthermore, it is to be understood that in someembodiments the software of the application can be distributed among aplurality of different servers (not shown).

It is also to be understood that the software of the invention willpreferably further include various Web-based applications written inHTML, PHP, Javascript, XML and AJAX accessible by the clients using asuitable browser (e.g., Safari, Internet Explorer, Mozilla Firefox,Google Chrome, Opera).

A significant aspect of the present invention is a systematic approachto optimizing bandwidth utilization and minimizing latency, whilerendering optimal graphics resolution for a specific display device 20.Latency is a particularly important issue of concern, and is related tobandwidth utilization and display graphics resolution. Time delaysbetween user input body motions and simulated actions on the outputdisplay device detract from the realism of a sports game. Furthermore,delays loading the next scene can also frustrate users. Another goal isto enable as seamless a user experience as possible, with almostinstantaneous display outputs in responses to input motions, with lessthan one second transitions from scene to scene of rich graphicscontent.

As an example of the impact of bandwidth utilization, a 5 MB (megabyte)video or photograph will take 40 seconds to download with a 1 Mb/s (T1)connection. The same video will take 8 seconds to download with a 5Mb/sec connection, which is the average household broadband connectionspeed in the United States. Hence, if the data density (number of bits)for the game is large, then the user will experience potentiallysignificant delays as the content is downloaded.

It is anticipated that in the next several years average bandwidthutilization will increase significantly in developed countries, toapproximately 50 Mb/s. This is due to the invention of 4G and LTEcellular data networks, and fixed line cable and telecommunicationsoperators upgrading their systems to remain competitive with 4G. At 50Mb/s the 5 MB file will take only 0.8 seconds to download. However,simultaneously over time, display devices are increasing in size andpixel resolution. As examples, in 2012, the average LCD TV displaydevice is 37″ in the US with a 1920×1080 pixel resolution and costs$300-$500, where the same resolution 46″ costs approximately $700 andthe 60″ displays cost less than $2000. By 2015 a 60″ LCD may be near the$700 price point, but the resolution will increase to 2560×1440. Hence,there are dueling factors of bandwidth utilization and displayresolution, both increasing in parallel over time.

As an example of latency, as the user swings the mobile device 10(assuming the mobile device and display device are on differentnetworks), there is a time delay as the data is transmitted across theInternet, to the gaming server 110 where computations are performed,then to the display device 20. This time delay is exacerbated if largebandwidth files are being transferred simultaneously to the displaydevice, exceeding the bandwidth utilization of the device, since themotion data essentially must get into a queue waiting in line with theother gaming data being transferred through the bottleneck. The methodsdisclosed herein optimize the system performance on the three dimensionsof (1) bandwidth utilization, (2) overall system latency, and (3)display device resolution.

In FIGS. 2 and 3, the overall system latency ΔT for sports motionsdetection and output display is:

ΔT=Δt _(swing Analysis) +Δt _(Network) ₁₂ +Δt _(Gaming Server) +Δt_(Network) ₂₃ +Δt _(Graphics Engine)  (1)

Where Δt_(swing Analysis) is the time for the sports motion analysis onthe mobile device, Δt_(Network) ₁₂ is the transmission time across thenetwork from the mobile device 10 to the gaming server 110,Δt_(Gaming Server) is the processing time at the gaming server 110,Δt_(Network) ₂₃ is the transmission time from the gaming server 110 tothe display device 20 and Δt_(Graphics Engine) is the processing andtime to display animations, images or other data on the display device20. The advantage of long polling, such as WebSockets, in the embodimentof FIG. 3, is that the motion data from the mobile device 10 isbroadcast to the gaming engine 110 as an event which in turn broadcaststo the display device 20. The latency is approximately 50 milliseconds(ms) between WebSocket connections in the continental United States.Using the architecture illustrated in FIG. 3 for small packets of data,such as motion data and user interface updates, the overall systemlatency is therefore primarily constrained by the motion analysisprocessing at the mobile device 10, the gaming engine processing, andthe graphics engine display, not the data transmission time across theInternet which is approximately Δt_(Network) ₁₂ +Δt_(Network) ₂₃ =100msec.

In practice, the architecture of FIG. 3 provides a near real-timesynchronization between the mobile device 10, gaming server 110 and webdisplay 20 for multiple simultaneous users. This architecture allowsnear real time synchronization of user activities on a mobile device 10and a web display device 20 while simultaneously enabling swing motiondata transfer to and from the gaming server 110. Additionally, thearchitecture of FIG. 3 is highly scalable, and could be implemented toaccommodate thousands of players playing simultaneously, withoutdeparting from the essential design. In that case, thousands ofdifferent games could be at various stages of completion at any giventime, and the architecture could also support various different types ofsports games, such as golf, baseball, bowling, etc., being managed bythe gaming server 110, at any given time.

These and other novel elements of the invention will become apparentfrom the following detailed description of the invention in the contextof a virtual multi-player golf game, two and four player tennis game anda multi-player baseball game. However, it is to be understood that thefollowing examples are not meant to be limiting.

Golf Game Example

Referring to FIGS. 4-10, the present invention will be further clarifiedby the following example of a golf game implemented using techniquesdescribed herein, according to an embodiment of the present invention.FIGS. 4( a) to 4(e) show the user experience and FIG. 5 is thecorresponding distributed golf gaming architecture.

In an embodiment, to access the distributed gaming platform 100, a userfirst downloads an application (“app”) to their mobile device 10. In anembodiment for the Apple iPhone 4/4s, the app is programmed in ObjectiveC, and utilizes the CoreMotion framework included in the Cocoa Touch SDK(software development kit) to gain access to, at 100 samples per second,built-in hardware-based sensors such as an accelerometer, a gyroscope,and a magnetometer. A layer above this called a “signal-processingpipeline” includes a platform-independent class of programs to providereal-time swing analysis calculations. On top of the signal-processingpipeline layer rests a graphics-based gaming presentation layer, whichprocesses data calculated by a signal processing engine, passes thesedata to the server based gaming rules engine, and presents the user withmobile device specific content to complement the gaming experience.

In an alternate embodiment, a mobile website can access the samehardware based sensors using simple Javascript event handlers in amobile browser. Accessing these sensors through a browser is generallyfar slower than the CoreMotion framework, however, with 10 samples persecond sampling with present technology. Here we use the same signalprocessing pipeline to analyze swing data, and an interactive Javascriptwebsite builds the graphical interaction on screen for the mobiledevice.

In FIG. 4 (a), the user logs into a designated web site using his or hermobile device 10, and then the user's web-enabled display 20 isconnected to the same web site, by opening any standard browser andnavigating thereto. As the user establishes the connections, in eachcase, a log-in page is presented that asks for the user's information.Upon log in, a virtual driving range or golf course is presented to theweb-enabled display device 20, downloaded from the gaming resourcedatabase 117 via the gaming server 110. However, during the initial loadof the web page to the display device 10, a light-weight gaming logicengine 120 can also be downloaded in the background. This web-basedgaming engine can be programmed as an asynchronous application, usingAJAX, for example.

In FIG. 4( b), once logged in on both devices, 10 and 20, the user canenter the driving range or choose to play games; in either case, he orshe can invite friends 30 to play. Invited friends, once logged-in ontheir own devices, can accept the invitations and join the host's game.The cloud-based gaming rules engine 115 manages clusters of players byjoining the records for each of the users in a player database to form atemporary table for each game being played. Each player with an accounthas his or her own set of database records in the user database 116.

In FIG. 4( c), once the game starts, each player selects a golf clubfrom their specific virtual golf bag and swings their own mobile device10, and, at “impact,” each device analyzes the swing and sends a smallpacket of swing data to the gaming server 110 where these data areupdated in the user database 116. The golf swing motion analysis isdescribed in detail in the following sub section. The interactionsbetween a player and the game rules engine 115, can be done usingvarious input devices of the mobile devices 10, such as by key entry,touching a touch screen, and, where available, even voice recognition.

These swing data are then passed to the display device 20, using one ofthree methods describe in sub section (2) following. In FIG. 4( d), adownloaded display device graphics engine 125 (using an algorithm tocalculate or estimate the ball flight) renders the ball flight 25 on thedisplay 20. Similarly, as friends hit their virtual balls, their motiondata is sent from their respective mobile devices 10 to the gamingserver 110, where these data are updated to the user database 116. InFIG. 4( e), they are then passed to the specific users, and ball flightsrendered in each of their specific environments, so that each playersalso sees the plurality of golf swing gaming motions from each of theirfriends, from their specific location in the gaming environment.

Users click or touch to advance to the location of their respective ballflight. The downloaded light-weight web-based gaming engine 120 containsthe logic for the display device to determine where the users are on thevirtual golf course given their golf swing, and to request theappropriate graphics display content from the gaming resource database117 via the gaming rules engine 115. The process then repeats, exceptnow the players are most likely in different locations on the golf hole.Player locations are updated to the user database 116, and the gamingengine 120 renders each player's respective ball flights in theirrespective location on the virtual golf course. Additionally, in anembodiment, players are able to communicate with one another, creating asocial network of game players. Such communication can be accomplishedby the game rules engine 115 having suitable IP voice-over, text chat,text message board applications, for example.

In addition to playing the game, users can also purchase a plurality ofvirtual goods and services. These include, but are not limited to: golflessons, upgraded golf clubs, custom bags or golf club covers, magicballs to mess up a friends shot, virtual prizes for winning tournamentsetc. As detailed in U.S. application Ser. No. 13/659,774 to Jeffery etal., entitled METHOD TO PROVIDE DYNAMIC CUSTOMIZED SPORTS INSTRUCTIONRESPONSIVE TO MOTION OF A MOBILE DEVICE, filed Oct. 24, 2012, thevirtual goods can also include customized golf instruction based uponanalysis of the users specific golf swing.

A related novel aspect of the present invention is a “virtual caddie”enabled by predictive analytics. Every swing a user takes in the systemis captured in the motion archive database 118. For each user shot,these data are mined using analytics software, and predictive modelsused. So for example, after 100 swings of the driver, if on average theuser hits 249 yards but slices 30 yards to the right, on the tee of aparticular hole the “virtual caddie” might recommend to play a threewood, in order to miss the water hazard 235 yards distant and 25 yardson the right.

The motion archive database 118 may also be augmented with data capturedon a physical golf course, through a user's manual input into theirmobile app via touching the screen, or voicing commands after each shot,or by a gyroscope and accelerometer physically attached to a golf cluband connected via Bluetooth to the mobile device. The virtual caddie canthen be extended to playing physical and virtual golf, so that on aphysical golf course similar advice is given to playing in the virtualcourse.

Additional technical aspects of the disclosed golf game are described inthe following sections: (1) Distributed gaming engine, (2) Mobile deviceswing analysis; and; (3) Display device optimization.

(1) Distributed Gaming Engine

FIG. 5 illustrates an embodiment of the gaming platform 100 for a golfgame. As discussed earlier, the gaming analysis is distributed acrossthe three major components of the system: the mobile devices 10, thegaming server 110, and the display devices 20. FIG. 5 provides anexample of different modes of play for four different players 30: A, B,C and D. It is understood that this example is illustrative and is notlimited to four players. As shown, player A has a mobile device 10 butdoes not have a display device 20. In this mode, the game graphics aredisplayed singularly on the mobile device 10 of the player A. The playerB is in a different geographic location from the player A and has accessto a display device 20. Gaming interaction and graphical display on thedisplay device 20 are described in the following text. Illustratively,players C and D are in the same geographic location, different fromusers A and B, with a display device 20. Users in the same geographiclocation may use a singular mobile device, configured to know theidentity of respective players using the device, or may have their ownrespective mobile devices. It is understood that the examples shown inFIG. 5 are not limited to a particular hardware manufacture.

Analysis of the golf swing is conducted on the mobile device 10 via themethod described in the following section. The output from this analysisincludes, but is not limited to, swing speed of the mobile phone, angleof the phone through impact (hook or slice), forearm rotation rate,wrist hinge rate, and swing path (inside outside or outside in). Thesedata are transmitted to the gaming server 110, which updates the userdatabase 116, manages different user interactions, and serves the gamingcontent, as needed. A relatively light-weight Javascript/AJAX gamingengine 120 can be downloaded to an HTML5-enabled display device webbrowser when the user logs in. This gaming engine 120 controls aspecific users display environment, given the users respective swingdata passed from the golf gaming server 110. The gaming engine 120 hasthe gaming logic of the golf game and a graphics engine 125 for ballflight simulation and other rendering. As discussed in detail in thefollowing sections, each golf hole is broken into segments correspondingto two-dimensional photographs or videos. The number of photographs foreach hole is selected to optimize both the user experience and thebandwidth and latency of the system, as disclosed in the followingsection. The grid locations for each hole are defined in advance foreach hole and are programmed in the Java code of the web browser gamingengine. The graphical content corresponding to each grid location foreach hole is stored in the gaming resource database 117.

Ball flight distance and direction is primarily determined by the clubhead speed, loft of the club, and angle at impact. For different golfclubs, the loft will be different. However, the speed of the club isdirectly proportional to the speed of the phone in the user's handsthrough impact. As described in the following section, we have conducteddetailed experiments with high-speed video cameras at 1,000 frames persecond to verify the accuracy of the speed of the phone and the clubhead speed for a golf driver. These data were compared to vendor tablesof ball flight distances for various clubs and club head speeds. Slicingor fading the ball reduces the yardage, and hooking or drawing the ballincreases the yardage for small degrees of draw, but then overallreduces the yardage for a hook of more than a few degrees.

Given the speed of the phone in the users hands, the height of the user,and the length of the club we are able to calculate the club head speed.More specifically, using a table look up for various golf clubs we cancalculate club head speeds for specific golf clubs, and map this speedinto ball flights for the various loft angles of each club, again via atable look up. The swing path and hook or slice angle are then used asfractional multipliers/dividers to accurately calculate the distance anddirection of the shot from the mobile phone sensor swing data.

FIGS. 6 (a) and (b) illustrate how each hole is divided into a virtualgrid 190. The length of the shot and the direction define an (X, Y)coordinate which is the end-point of the shot. This (X, Y) shotend-point corresponds to a specific grid location, see FIG. 6 (a). Foreach grid location, media 119 (which can be image, sprite, and/or video)is stored in the gaming resource database 117. Given the (X, Y)coordinates of the shot end point the web page graphics engine queriesthe resource database 117 and, via a table look up, displays the media119 corresponding to the (X, Y) location. The user experience is to thenview media on the web page of the flag from the perspective of standingat the (X, Y) coordinate location, see FIG. 6( b). As the user swingsagain, the next (X, Y) coordinate is calculated from the swing speed,club selected and angle of the club head at impact. The graphic enginethen displays the appropriate image from the database for the newlocation.

The swing history for each user is updated to the motion archivedatabase 118. These data are used for analytics of user performance overtime, as described previously. The user database 116 is also updated,tracking the progress of multiple players in the game. These data areused as master data to update the gaming engine 120, and enable drawingof other users' avatars and ball flight simulation on a specific usersdisplay screen.

Simulated ball flight is rendered in 2-D using a 3-D graphics enginemodule 125 which is part of the gaming engine 120. For a 1600×900 pixeldisplay resolution the golf ball's flight following a swing is achievedby animating the ball as an individual object on top of the background.The ball begins centered on the page located near the bottom and at asize of 35 pixels wide by 35 pixels tall. Once a swing is detected, itsdistance and direction is passed into the gaming engine where it is usedin determining the exact path of the ball flight. The ball flight is anexponential curve that passes from its starting position to a highposition determined by the club used:

+0 pixels for the putter (this creates a straight path resembling a ballrolling)

+200 pixels for the driver

+225 to +325 pixels for the irons

+350 pixels for wedges.

The ball then ends at a Y position in pixels that is equal to: theheight of the image's horizon+(the current distance from the flag−theforward distance the ball was hit)/2 and an X position in pixels isequal to: the pixel center of the image+the lateral distance the ballwas hit*4.

Throughout the ball flight, the ball is shown “shrinking” at an invertedexponential rate that ends at 3 pixels+170/the yardage of the currentswing. The pixel numbers given above are understood to be illustrativeand not limiting.

A particularly important feature of the invention is the near real timerendering of ball flight following a mobile device golf swing, withminimal latency. While the game is being played, the website isrepeatedly polling the user database 116, looking for an update. When anupdate is detected, the swing data is taken and passed into the gameengine 120, triggering a simulation of ball flight driven by the swingdata. How high on screen the ball flies, how far it falls, how far tothe left or right it travels, how small the ball becomes, and how longthe animation takes, are influenced by this swing data. Ball flightsfrom participants are rendered on each player's respective screen. If aplurality of players are at the virtual driving range, for example,highest yardages are displayed. If players are in a game of golf, eachplayer moves to a new position on the hole determined by their previousswing. In the game, players proceed until they are virtually situated atthe putting green, were they simulate putting, and then advance to thenext hole once the ball goes into the hole.

The inventors have implemented multiple methods for real time graphicaldisplay of ball flight following a swing of a mobile device. The currentAJAX solution, “short polling”, is very scalable and can be used toupdate content in real time for large numbers of users.

While the default polling used is once per second, polling morefrequently, such as 5- or 6-times per second, is possible. With AJAXpolling or “short polling” the issue becomes one of available bandwidth.Even where data is not being transferred, merely checking for an eventtakes up some bandwidth. So, if there are a large number of users, forexample 200,000, polling at 5 times per second requires a considerableamount of bandwidth. However, bandwidth generally scales better thanprocessing power and storage space. Additionally, the polling rate canbe dynamically adjusted to manage bandwidth usage.

Referring again to FIG. 3, an architecture incorporating “long polling”is illustrated. The architecture uses WebSocket web technology. Theinventors have created a scalable long polling architecture such thatthere is hardly any lag as the server “pushes” the new data to thewebsite. With AJAX polling we wait for the website to check the databaseonce per half second and there can be a perceptible lag.

Long polling allows for bi-directional transmission of data and onepossible technology for long polling is a WebSocket, which is a webprotocol providing full duplex communications channels over a single TCPconnection. The WebSocket API is being standardized by the W3C, and theWebSocket protocol has been standardized by the IETF as RFC 6455, whichis incorporated herein by reference in its entirety.

FIG. 3 illustrates a method via long polling architecture to control andnavigate a web display using a mobile device as a controller, and totransmit sports motion data captured by the mobile devices across thenetwork. The phone and web display devices can be in the same ordifferent geographical locations. The communication between the mobiledevices and web display devices takes place via the use of web sockettechnology. FIG. 5 is an embodiment of the architectures of FIG. 2specifically for golf and can be implemented using the short pollingmethod or the long polling method of FIG. 3.

(2) Mobile Device Golf Swing Analysis

An important aspect of the present invention is the motion analyzer 130which uses data from an accelerometer and gyroscope embedded within themobile device 10, following application Ser. No. 13/655,366 to Jefferyet al., entitled METHOD AND SYSTEM TO ANALYZE SPORTS MOTIONS USINGMOTION SENSORS OF A MOBILE DEVICE, filed Oct. 18, 2012. A particularchallenge that the invention overcomes involves how to accuratelyanalyze a golf swing without actually hitting a ball or holding a clubor racquet. While a swing analysis technique is described for golf, itis to be understood that the approach described herein is applicable toother motions such as, but not limited to, hitting or throwing a ball,aiming and shooting a gun, or casting a fishing rod for examples. Thelast section generalizes the motion analysis method to other sports suchas bowling, tennis and baseball.

FIG. 7 illustrates the pitch (a) and roll (b) of the mobile device 10during an example full golf swing. An important element of the presentinvention is the calibration of the mobile device 10 by holding themobile device 10 still in the address position (position 1). The motionsignature for the pitch then increases in the backswing (position 2) andhas a local minimum at the top of the golf backswing (position 3).However, the minimum (position 3) is an artifact of the pitch motionsensor rotating more than 180 degrees. In actuality, the pitch continuesto increase to a maximum, greater than 180 degrees, at the top of thebackswing. However, limitations of the sensor constrain the motionsignature to 0 to 180 degrees. The pitch data continues to decrease inthe downswing (position 4), back to the impact point (position 5), asshown.

Accuracy Analysis

Note that at the impact point (position 5), the mobile device 10 hasreturned to near the initial calibration point (position 1), which forgolf is the hand position at impact with a virtual golf ball and a localminimum. For a high speed golf swing the minimum at the impact pointdoes not return exactly to the calibration zero due to resolution limitsof the gyroscope. Determining the impact point is of vital importancebecause the roll of the mobile device 10 at this point defines the hookor slice of the club. In other sports, the impact point is vital indetermining the hook and slice of a bat or a racquet, and/or the releasepoint in throwing or casting sports. From the impact point, the golfswing continues through follow through, positions (6) and (7).

In summary, pitch data, or the rotation around the axis that cuts themobile device 10 into top and bottom halves when looking at the screen(X-axis) (see FIG. 1) is the most telling data stream as a golfer movesthrough their swing. Impact can be found at the major minimum thatapproaches the starting calibration point (which is defined as “zero” bytaking the average of all phone position/orientation data over thecourse of one second, for example, taken prior to the swing when thegolfer is in their set-up position). To bring context, in a golfer'sswing, pitch data rises as the golfer goes into their backswing, returnsto calibration as he or she swing through impact, then rises again as heor she moves into their follow through. Impact is the pitch positionthat gets closest to the set-up, or calibration point.

In an embodiment, the impact point for a full golf swing is selected tobe the second minimum of pitch using a crawler algorithm. In anotherembodiment, the minimum can be confirmed by aligning it with a spike inZ-acceleration. When more than one major minimum in pitch is found, theminimum selected as impact is determined by which point has the greatestZ-acceleration. This confirmation helps in cases where a golfer'sbackswing or follow-through rotation is so great (near 360 degreerotation from set-up) that the gyroscope flips completely and createsextra minimums near calibration.

Once impact is found, swing accuracy is determined by subtracting rolldata at impact from roll data at calibration. Roll data, or the rotationaround the axis that cuts the phone into left and right halves whenlooking at the screen (Y-axis) describes “open and closed” facepositions on the club head. FIG. 7 (b) shows an expanded view of theroll data. Swings that return a negative difference mean that the userover-rotated at impact which implies a closed face at impact and aresulting draw or hook depending on the amount. Swings that return apositive difference mean that the user under-rotated at impact whichimplies an open face at impact and a resulting fade or slice. Swingsthat return a near zero value mean the club face very closely matchedcalibration orientation at impact and imply a straight ball flight.

Speed Analysis

Club head speed is a critical parameter for golf in defining the ballflight distance. The golf club manufacturers have empirical tables whichdetail the ball flight distance for golf balls hit by club heads movingat a specific swing speeds. Such tables also take into consideration theclub type (e.g., driver, 5-iron, putter), the club head loft, the shaftstiffness, and other variables that impact the ball flight.

Swing speed is a complex calculation due to the mechanics of sportsmotions. The challenge is that the sensors measure motions of the handswhereas we are interested in calculating the speed of virtual sportsequipment, such as a golf club head. Extensive experiments withprofessional athletes were conducted using appropriately fitted sportsequipment to understand how hand and arm motions translate to the motionsensor data outputs. While the analysis for golf is illustrated, it isto be appreciated that the present method is generalizable to othersports motions, such as those found in the sports of baseball, tennis,bowling, basketball, American football and table tennis; however, theseexamples are understood to not be limiting.

FIG. 8 (b) illustrates the swing motion elements for a full golf swing.If the club is swung exactly in line with the arms, then the mobiledevice velocity, V, is related to the club head velocity (V_(club head))by:

V _(club head) =V×(Arm Length+Club Length)/Arm Length  (2)

However, expert players hinge their wrist and rotate their forearms toincrease the velocity of the club head through the ball. These hingingand rotating motions can dramatically increase the velocity of the clubhead through impact, so that Equation (2) is a gross under estimate ofthe golf swing speed for most golfers. It is a good for putting,however, since there is no hinging of the wrists.

FIG. 8( a) illustrates specifically how we calculate the speed of themobile device 10 for a golf swing. The motion signature for the pitch ofthe mobile device 10 for an example full golf swing is graphicallyillustrated. Shown below is the corresponding sports motion with points(4), (5) and (6) in pitch data labeled on the swing. We first find theimpact point in pitch data, defined as the local minimum of pitch at thebottom of the swing (point 5). We then look forward and back in pitchdata by 60 degrees. These data points, assuming proper wrist hinging,align with positions in the swing (4) and (6). Generally, about onetenth of a second passes between these two positions, so that given theplayer's arm length we can find the mobile device speed 10 around impactby dividing the length of a 120 degree arc where the radius of the arcis equal to the arm length by the amount of time passed: This deliversthe speed of the mobile device 10 (hand speed). A similar method can beused for chipping but with a shorter arc length of 55 degrees or lessdue to the reduced swing length.

It has been found, using high speed video clocking, that the driver clubhead speed can be as slow as 2.4 times hand speed (this is in the caseof a user swinging a club with rigid arms, forearms, and wrists) or asfast as 6 times hand speed (in the case of a world class professionalgolfer). The difference between these two multipliers comes from thecombination of forearm rotation and wrist hinge which allow golfers toforce the club head to travel through a much greater arc length(sometimes even close to 180 degrees) in the time it takes the hands totravel through the 90 degrees of arc length around impact. Themultiplier we choose is driven directly by gyroscope accelerationthrough impact on the Z and Y axis (yaw and roll) which account forwrist hinge and forearm rotation respectively.

From detailed experiments with the iPhone 4 and 4s it was found that thegyroscope is particularly accurate, so that the roll data is very goodto predict hook or slice within approximately half a degree. Theaccelerometer data from the iPhone 4, however, is “noisy”, and is notparticularly accurate over the entire golf swing, but does work well formeasuring forearm rotation rate around impact. This is why we divide theswing into portions and calculate an average velocity, V, of the mobiledevice through impact:

$\begin{matrix}{V = \frac{D_{2} - D_{1}}{t_{2} - t_{1}}} & (3)\end{matrix}$

where D₂−D₁ is the distance between points (4) and (6) in FIG. 8; andt₂−t₁ is the time taken to cover the distance. A shorter distance ispreferred, since this enables a closer approximation of theinstantaneous velocity at the impact point. However the 0.01 secresolution of the current gyroscope requires us to use the 120 degreearc. In the future, as the sampling resolution of the gyroscopeincreases, a 30 degree arc or less will be preferred.

Equation (3) is an approximation of the actual instantaneous velocity ofthe mobile device, and is only a first order approximation of the speedof the golf club head, since it does not include the wrist hinge orforearm rotation described above. Via detailed experiments with ahigh-speed video camera we were able to find multipliers for thesevariables, with the result of calculating club head speed within +/−10%for a variety of swing types. From club head speed we can predict ballflight distance in ideal conditions.

We envision that the data quality output from the accelerometer willimprove dramatically in future versions of iPhone or Android basedphones. In an embodiment of the present invention, the velocity of amobile device 10 (having a sufficiently accurate accelerometer) atimpact is calculated by integrating the acceleration (a_(x), a_(y),a_(z)) from the top of the backswing (t_(bs)) to the zero (t₀) of themobile device:

V _(x)=∫_(t) _(bs) ^(t) ⁰ a _(x) dx

V _(y)=∫_(t) _(bs) ^(t) ⁰ a _(y) dy

V _(z)=∫_(t) _(bs) ^(t) ⁰ a _(z) dz  (4)

with the total mobile device velocity at impact:

V=√{square root over (V _(x) ² +V _(y) ² +V _(z) ²)}  (5)

where t₀−t_(bs) is the time between the minimal at the top of the backswing (t_(bs)) measured from the pitch data and the zero at the bottomof the swing at impact, t₀. The integrals are calculating in thesoftware using a fourth order Runge-Kutta algorithm. See for example,William H. Press et al, Numerical Recipes 3rd Edition: The Art ofScientific Computing, 2007.

The velocity component vectors (5) are difficult to accurately calculatewith the current version of the accelerometers, since the internalaccelerometer has a noisy output, hence why we currently use the averagemethod equation (3). Data on the swing motion is presented to the userand stored, local to the app and on a server in the user's account, forlongitudinal comparisons of swing consistency improvement.

The user can also attach the phone to their golf club via a cradle andcompare actual practice swings to the computed swings for distance andaccuracy. We use a similar analysis when the phone is attached to theclub, but the multipliers are different primarily due to users swingingthe golf club slower than the phone, the phone is lighter than a golfclub so one's hands naturally go faster.

As an additional example of swing analysis we consider putting, ratherthan the full swing of a golf club. PING, Inc. has previously created aniPhone App for putting. Their prior art invention has three significantlimitations however: Their method (1) requires an attachment to aputter, (2) requires impact with a physical ball, and (3) is notaccurate for long putts (greater than approximately 20 feet).

The method described herein does not have any of these limitations.Similar to the full swing described above, the user holds the mobiledevice 10 as if it were a putter, and after one second of being heldstill it vibrates: the phone is ready. The user then putts an imaginary(virtual) ball. Compared to the full swing, the pitch data from thephone is now a relatively smooth sine wave function with a minimum atimpact. The putter stroke is analyzed similar to the full golf swing,but with average velocity calculated from Eq. 3 where D₁ and D₂ are therespective maximum distances pull back and stroke through impact withthe ball. An advantage of the putter stroke is that the function issmooth and the speed is relatively slow compared to the full golf swing.Hence, equations (4) and (5) can also be used to calculate aninstantaneous velocity at impact—we use both methods, integration ofequations (4) and average velocity from Eq. (3), with a scale multiplierfor the length of the putter for speed at the putter head at impact witha ball, see Eq. (2). For long putts the acceleration method becomesincreasingly inaccurate, hence the average velocity method providesbetter results with a multiplier derived from empirical measurements.

From the speed of the putter head the distance the ball travels can becalculated assuming ideal conditions. Most important, however, is thatwe are able to quantify mobile device roll angle differences at impact(similar to hook or slice for the full swing) without impacting aphysical ball. We can also analyze the gyroscope acceleration data forerrors such as deceleration through the putt, or a left pull or rightpush (these last two errors are identified from the combination of thesecond integral of acceleration, and the roll data). Data on swingmotion accuracy is also presented to the user and stored, local to theapp and on the server in the user's account, for longitudinalcomparisons of putting consistency improvement.

Our method for putting, in conjunction with the distributed gamingplatform, overcomes a major deficiency of the golf gaming prior art:putting is notoriously unreliable in a virtual golf game. Expertgolfers, who play on the PGA tour, are known to consistently three orfour put in golf computer games, where they would one or two put inphysical golf. As discussed previously, our method using the mobiledevice gyroscope is considerably more accurate than a Nintendo Wiicontroller, for example, so we are able to replicate professional golfputting in the virtual golf game.

Multi-Sensor Impact Detection

A technique for detecting the “impact point” with a virtual object usinga single type of rotational data (pitch) of the mobile device 10 wasdescribed above. The signature of the sports motion (pitch data as afunction of time) was analyzed for characteristics, specific to the typeof sports motion (e.g., a full golf swing). The a priori structure ofthe sports motion signature was necessary to isolate the location intime and space of the virtual impact point. In another embodiment, weextend our inventive concept to enable impact point detection for manydifferent motion signatures, and for a wide range of motions.

FIGS. 8( a) and (b) illustrate changes in pitch and yaw, respectively,of the mobile device 10 during an example full golf swing. In this case,the mobile device used was an Apple iPhone 4Gs. As noted above,calibration of the mobile device 10 is accomplished by holding themobile device 10 still in the address position (position 1). The motionsignature for the pitch then increases in the backswing, (position 2)and has a local minimum at the top of the golf backswing (position 3).However, the minimum (position 3) is an artifact of the pitch motionsensor rotating more than 180 degrees. As noted previously, inactuality, the pitch continues to increase to a maximum, greater than180 degrees, at the top of the backswing. However, limitations of thesensor constrain the motion signature to 0 to 180 degrees. The pitchdata continues to decrease in the downswing (position 4), back to theimpact point (position 5), as shown.

From detailed experiments with high speed cameras we found that thevirtual impact point (position 5) is a local minimum of pitch, where themobile device has returned near to the initial address position(position 1). From the impact point (position 5), the golf swingcontinues through follow through (positions 6 and 7).

Determining the impact point is of vital importance because the roll ofthe phone at this point defines the hook or slice of the club, bat orracquet, and/or the release point in throwing or casting sports. Theinventors have previously used crawler software to search the pitchmotion signature for the second minimum. However this method is notuniversally applicable, since different swings have different motionsignatures.

Different types of golf swings can have different motion signatures.Specifically, it was found that for older people playing golf, there isa tendency to abbreviate the back swing, so that the swing signaturelooks more like a chip, and is missing the first minimum in FIG. 9( a).

Hence, the crawler method which searches for a specific feature of themotion signature of a single motion sensor output produces erroneousresults. Specifically, in the case of golf, the motion signature for aprofessional golfer's full swing has an impact point at the secondminimum of pitch data. However, a short swing does not have a secondminimum; hence searching for the second minimum in these types of shotswill create an error. Accordingly, the method of using motion signaturedata for single type of rotational measurement to obtain the impactpoint has limitations. In the present embodiment, we use at least twodifferent types of rotational measurements (pitch and yaw in golf forexample) to calculate the impact point and/or release point to overcomethis.

FIG. 9( b) illustrates the yaw of the mobile device through a full golfswing. In the case of golf and baseball swings, the yaw is changingrapidly through the impact point (5). Hence, using both pitch and yawmotion sensor data, one can isolate the impact zone by looking for theminimum of pitch motion data that has a maximum yaw derivative (changein yaw). This method works for all types of golf swings, and enables theaccurate impact point detection for chips and putts.

A significant advantage of the multi-sensor impact point detectionmethod is to enable minimization of latency in the motion analysis atthe mobile device. Specifically for golf, different users can make verydifferent golf swings, and can randomly delay their swing start afterthe calibration point. The slowest swings are completed approximately 5seconds after calibration, while the fastest swings are only 2 seconds.One method is to collect data for 5 seconds after the calibration pointin order to capture the vast majority of swings, and then use a crawlerto detect the impact point minimum. However, this method is inefficientas it adds a delay of up to 3 seconds, depending upon the speed of theswing, and captures additional data that slows processing on the mobiledevice.

In our method, the key event is when the yaw equals the yaw at thecalibration point, or equivalently crosses zero, see FIG. 9 (b). In thecase of a slice the impact point will be several hundredths of a secondafter the yaw crosses zero, and in the case of a hook the impact pointwill be several hundredths of a second before the yaw crosses thecalibration point. Hence the yaw zero crossing serves as an indicator tolocate the impact point at the bottom of the golf swing. Specifically,we look for when the yaw crosses zero and truncate the data after anadditional 150 msec: the impact point will be found approximately plusor minus 100 msec from yaw zero crossing.

Assuming a computational processing time of less than 10 msec, the totalimpact detection and swing analysis time with our method is less than200 msec. Therefore, for a golf swing the latency of the mobile devicemotion analysis, Δt_(Swing Analysis) in Equ. (1), can be reduced fromapproximately 3 sec to less than 200 msec using our original andinventive multi-sensor impact detection method. Assuming the overallpublic Internet latency in the continental United States of 50 msec forsmall data packet transfer, Δt_(Network) ₁₂ +Δt_(Network) ₂₃ =100 msecin Equ. (1), the approximate total delay from the impact point on themobile device to ball flight on the display device is approximately 350msec, where it is understood the data transfer may encompass thousandsof miles out from the mobile device 10 to the gaming server 110 and backto the display device 20. A user takes approximately 500 msec tocomplete their follow through in a golf swing, motions 5-7 in FIG. 7.Hence the ball flight appears near instantaneously on the displaydevices 20 to the multiple simultaneous users 30 (A, B, C and D) in thegolf gaming system FIG. 5.

It is understood that the method described herein to reduce the mobiledevice motion analysis latency is not limited to golf swings and isgeneralizable to other motions. Furthermore the multiple sensors may notbe pitch and yaw of the mobile device but can be any two of theplurality of sensor outputs available on the mobile device.

As described in this invention, data on swing motion accuracy ispresented to the user and stored in the gaming server 110 in the motionarchive database 118, for longitudinal comparisons of swing, putting andchipping consistency improvement. These data are then the foundation forthe “Virtual Caddie” analytics disclosed above and for providingcustomized golf instruction, as disclosed in detailed in U.S.application Ser. No. 13/659,774 to Jeffery et al., entitled METHOD TOPROVIDE DYNAMIC CUSTOMIZED SPORTS INSTRUCTION RESPONSIVE TO MOTION OF AMOBILE DEVICE, filed Oct. 24, 2012.

(3) Display Device Optimization

Yet another advantage of the present invention compared to the prior artis an architecture designed to operate in a distributed Internetenvironment whereby optimizing display device bandwidth utilization andminimizing overall latency—in the golf context, the time delay betweenswinging the mobile device and rendering the ball flight on the displaydevice, and rendering the next shot display media. Minimizing latencywas discussed in Eq. (1) in the context of passing swing data from themobile device 10 to the gaming server 110, and then to the graphicsengine 120. Here we focus on graphics resolution and method to optimizefor a specific user's display device Internet connection speed(bandwidth utilization).

Rendering a 3-D game such as golf can take considerable computing power,and the graphics quality of prior art console based games is limited bythis processing. The present approach is substantially different fromconsole-based games in that the golf holes are each segmented and imagesare mapped to the segments. In an embodiment, currently availableimaging technology such as high dynamic range (HDR) cameras are used.Images can be further enhanced via cinemagraphs (short video clips thatcycle) and sprites (short videos that can be controlled by the graphicsengine) (as shown in FIG. 10), so that trees, a flag, and clouds appearto move to the wind, for example. Instead of photographs the images canbe full screen video, such as compressed high definition video, HDRvideo, or other imaging technology not yet invented. The effect can bestunning, and has a low data density and computing requirement for eachshot. Although the images used can be (or can be based upon) digitalimages of an actual golf course taken with photographic equipment, it isto be understood that the digital images do not have to correspond to anactual golf course, but could, for example, be entirely an artist'srendition of a golf course or represent a simplification of an actualgolf course's terrain.

Cascading style sheets (CSS), supported in web browsers since 2000,enable formatting of graphics and text in a web page. One feature of CSSis to assign a number to the layers of graphics on a page, called theZ-index. The Z-index defines both the number of the layer and therespective order of the layer in the stack of images that comprise aparticular web page.

FIG. 10 provides an illustrative example of our technique using CSS toadd depth to images in the simulated golf game. This approach minimizesgraphics processing at the display device, which reduces latency. AZ-index of 300 is assigned to the background image 200, on top of imageare animated clouds 210 and obstructions 220 and 230, which are layersat specific yardages. For example, a tree at 100 yards, 230, and bushesand trees 220 at 150 yards or a are each assigned respective Z-indicesof 100 and 150, respectively.

The ball flight 25 initially has a Z index of 300, so that it isdisplayed on the main background, however depending on the ball flightdistance, and hook or slice, the Z-index is changed. Assuming the ballflight is 120 yards with a slice to the right, then the Z-index of theball flight 25 is changed to 125 so that it falls behind the tree layer100 and in front of the bush and tree layer 150, for example. Hence, wedynamically change the ball flight Z-index to create the effect of depthin the 2-D image environment so that the ball falls behind layerscorresponding to specific distances. This method is not limited to 2-Dphotographs, but can also be applied to applicable to digital video, HDRvideo or other imaging technology not yet invented.

We further illustrate the novel aspects of our invention by disclosing amethod to reduce the latency and optimize the bandwidth utilization ofthe display device.

TABLE 1 Comparisons of image densities in prior art methods of digitalgolf games, where “Aquimo” is the new inventive method. Images (Par 3)Images (Par 4) Images (Par 5) Aquimo 50 75 100 Method 1 100 150 200Method 2 200 300 400

Table 1 is a comparison of the new inventive method (“Aquimo”) to otherrepresentative methods, labeled Method 2 and Method 3, respectively.Specifically we use less than 50 images for a par 3, 75 for a par 4, and100 for a par 5 where other methods use 2× or 4× this amount. Tables2(a)-2(c) show the representative load times in seconds for 10% of theseimages for representative bandwidths of 5, 20, and 50 Mb/s,respectively. Available bandwidth increases over time, and our methodspecifically optimizes on the dimensions of image resolution andpre-load times of images, and is always better than the prior art.

TABLE 2a Low Bandwidth (5 Mb/sec). 10% Pre-Load Load Time (sec) @ 5Mb/sec Images Per Shot Low Med High Ai Golf 5 6 16 40 Method 1 10 12 3280 Method 2 20 24 64 60

TABLE 2b Medium Bandwidth (10 Mb/sec). 10% Pre-Load Load Time (sec) @ 10Mb/sec Images Per Shot Low Med High AI Golf 5 3 8 20 Method 1 10 6 16 40Method 2 20 12 32 80

TABLE 2c High Bandwidth (50 Mb/sec). 10% Pre-Load Load Time (sec) @ 50Mb/sec Images Per Shot Low Med High AI Golf 5 0.6 1.6 4 Method 1 10 1.23.2 8 Method 2 20 2.4 6.4 16

As an example, we use analytics of past player swing motions to predictfuture ball flights. So for example, given the average driver distance,hook or slice of the user, and standard deviations of these swingmetrics, we can predict the top 5 areas on the course, corresponding toenhanced images, where the ball is likely to land. The more granularmethods (Method 2 and 3 in Tables 2a-2c) must load many more images tocover the same areas. Tables 2a-2c shows the comparison assuming a 10%pre load for all methods, and for the three bandwidths with low, medium,and high-resolution images.

Our goal is to provide the best graphical experience to the user aspossible while factoring in the bandwidth utilization of the usersdisplay device. So for example, a user with a relatively low bandwidthconnection of 5 Mb/s will be served lower resolution images, with a 6sec pre load time for the next 5 images—this is acceptable given theanticipated time the user spends selecting golf club, talking withfriends etc. However, if the user has a 50 Mb/s connection, we willserve high-resolution images, with a pre-load time of 4 sec for 5images.

The bandwidth utilization for a specific display device is measured asfollows: A Javascript variable is defined, startLoad, set to the currenttime as digital image for a game screen (2-D image, cinemagraphs,sprites etc.) totaling approximately 2 MB are transferred from thegaming logic server. A second variable called finishLoad is defined asthe image finishes loading: finishLoad−startLoad=time. If time is morethan 4 seconds for a single image we reduce the resolution of thedigital content, and if the load time is under a second, the gamingdigital content resolution is increased.

The user therefore experiences the highest resolution images possiblewith a reasonable background pre-load time. The effect is aninstantaneous transition from shot to shot with the highest resolutionimages possible matched to the bandwidth utilization of the user. Othermethods, illustrated as Method 2 and 3 in Table 2, do not optimize onthese dimensions and therefore have prohibitive pre-load download times,causing potentially significant time delays to start the game, intransitions between shots or holes, or less than optimal imageresolutions.

Additional Sports Game Examples

The techniques described herein are generalizable to a multitude ofgames that involve body motion, throwing, or hitting a ball. As furtherexamples, we describe bowling, tennis, and baseball. However, themethods and systems of the present invention are not limited to golf orthese other sports, and are applicable to many other sports games, suchas motorsports, American football, hockey, rugby, etc. Additionally, itis to be understood that the methods and systems of the presentinvention may be applicable to other genres besides sports games.

(1) Bowling

The bowling game can be played by two people against each other oropposing teams. Each user (or team) “sees” a main view which is theframe of the bowling alley, a close-up view of impact with the pin, andthey can also zoom out and see lanes on either side where friends areplaying simultaneously. Each can be photographs, 2-D artist renderingspreferably with cinemagraphs for flashing lights on the score board,crowd cheering, etc. or the main image can be full screen video.

An advantage of our method is that the mobile phone motion sensors canbe used to more accurately model the bowling swing, compared to priorart such as a Nintendo Wii controller. So that the speed of the throw,the direction of the throw, and the angular rotation, which imparts aspin rate to the bowling ball, can also be measured. For each throw theuser first zeros the phone to start with the hand by their side andfacing the center of the display device. They feel a vibration, or hearan audio “swing,” and then go through a bowling swing motion.

Similar to the golf game, the swing is analyzed on the mobile device 10,and analyzed data are passed to the bowling gaming server 110, which isthen passed to the display device 20 using one of the methods describedpreviously. The bowling ball trajectory is drawn dynamically via thedownloaded display device graphics engine 125. Sprites are used to modelthe various pin motions and fall according to the logic programmed intothe web based gaming engine 120, which is dependent upon the velocity,trajectory and spin rate of the ball passed for the mobile phone swinganalysis. We use the same method of pre-loading content and minimizinglatency as in the golf game described previously. Bowling instructioncan also be incorporated into the gaming environment, following U.S.application Ser. No. 13/659,774 to Jeffery et al., entitled METHOD TOPROVIDE DYNAMIC CUSTOMIZED SPORTS INSTRUCTION RESPONSIVE TO MOTION OF AMOBILE DEVICE, filed Oct. 24, 2012.

(2) Tennis

Tennis is played between two or four players on a court with a net. Wedescribe the embodiment for two players, but the method is generalizableto four with multiple games played simultaneously by different players.Photographs are taken of various areas of the tennis court from theperspective of the players. We use a minimal set of photographs that arepre-loaded into the environment in order to enable instantaneous displayfor the user. These 2-D photographs are enhanced with cinemegraphs ofthe crowd cheering and the clouds moving for example, and by sprites ofthe ball boy running across the court to grab a ball that hits the net.Alternately, full screen video can be used in place of photographsenhanced by cinemegraphs.

Sprites are created for avatars of the players, mimicking the majorshots: serve, forehand, backhand, lob shot etc. These sprites arecontrolled by the web based tennis gaming engine, downloaded to thedisplay device web page. The ball flight is rendered dynamically by thedownloaded graphics display engine, with input data from the mobilephone motion sensors.

The tennis swing is analyzed using motion sensors in the mobile phone incombination with the global positioning sensor. We zero the phone at thebeginning of the serve, where the user's hands are up preparing for aserve. We can then analyze the pitch and roll of the phone and thevelocity of the phone through impact with the virtual ball—these datadefine the direction and spin imparted to the virtual ball.

Similarly, backhand, forehand and lob shot motions are analyzed. Forthese we look for specific rotational motions in the data synchronizedwith when the virtual ball would come over the net. We also incorporateGPS data to know if the player has shifted to the right or left of thescreen, or has stepped forward, towards the net. These data are passedto the tennis gaming engine, so that the player sees the court changedynamically in response to their positions. For example, if the playersteps forward on the right side of the screen they see the 2-D imageclose to the net on the right side of the court.

Minimizing latency is particularly important in tennis, due to the fastpace. There are significant pauses between each shot, so that there areperiodic opportunities to re-calibrate the zero of each user's mobilephone. In a preferred embodiment the mobile device 10 is simultaneouslyconnected to the web based gaming server 110 and the display device 20via a local socket connection 75. This method enables direct back andforth data transfer between the local game components.

Hence the motion analysis is almost instantaneously passed to the localgaming engine 120 to display the ball flight. The ball takesapproximately one second to fly across the net with a bounce, and weemploy 0.2 sec polling or a WebSocket (FIG. 3) to transmit these mobilephone data to the other player(s) display for graphical rendering. Weare able to anticipate ball motion and send ‘pre impact detection’ datafor example, so as to have the avatar make a pre return swing motion,thus synchronizing play with minimal latency.

Additionally, tennis instruction can be incorporated into the gamingenvironment, following U.S. application Ser. No. 13/659,774 to Jefferyet al., entitled METHOD TO PROVIDE DYNAMIC CUSTOMIZED SPORTS INSTRUCTIONRESPONSIVE TO MOTION OF A MOBILE DEVICE, filed Oct. 24, 2012.

(3) Baseball

Baseball is particularly suited to the disclosed method. The gamingresource database 117 can include 2-D photographs or videos takensystematically at various positions on a baseball diamond. Photographscan be enhanced by cinemagraphs for the crowd, clouds moving, etc.Sprites are also used to enhance the images for fireworks and aircraftfly overs, for example.

The game can be single player batting against a virtual team, or twoteams of multiple players, for example. For each player/position wecreate a database 117 of sprites for catching, and throwing. Forexample, the first base avatar will predominantly catch the ball frommultiple directions with a foot on the base, will throw the ball back tothe pitcher, and may occasional throw to second, third or home. Hencethese sprites can be pre-loaded depending upon the sequence of the game.

The gaming rules engine 115 determines multiple player interactions,interfaces with the gaming resource database 117 and the user databases116, and the web site gaming engine 120 and graphics engines 125 aredownloaded on the specific users display devices 20. Swing and throwingmotion analysis is conducted on the users mobile devices 10. So forexample, swinging the bat is accomplished by swinging the mobile device.We define a virtual strike zone on the display device, and users swingat virtual balls thrown by the pitcher avatar into this zone. We use themethod described in the following section to define the speed of theswing and the swing path. The timing of the swing is used to approximateif the mobile device (bat) missed the ball for a strike, or potentiallyhit the ball. The gaming rules engine 115 defines a set of swings forcorresponding pitches that results in various hits—base hits, fly ball,home run etc. The gaming logic engine 120 then determines the ballflight in response to the mobile device swing, and the sprite playeranimation responses. The various players may be controlled by virtualteammates—they see the respective 2-D photograph or video of the fieldand sprite player avatars for their respective locations. We use themotion sensors to analyze a throw of a ball, where a virtual glove onthe screen catches the ball.

In a preferred embodiment strikes or hits are determined using thefollowing method. The time t_(ball flight), it takes for the virtualpitch to reach the player can be calculated from t_(ball flight)=d/vwhere d is the distance from the pitcher to home plate (60.5 feet formajor league baseball or 45 feet for little league, as examples) and vis the velocity of the pitch. Assuming a 95 mph pitch in major leaguebaseball, the time of flight of the baseball from the pitcher to homeplate is 0.43 seconds. That is, t_(ball flight)=0.43 seconds. Thecloud-based engine compares the time stamp of the thrown pitch,t_(pitch), plus t_(ball flight) to the time stamp of the impact point,t_(impact point). If they coincide within a predetermined time interval

Δt=|t _(impact point)−(t _(pitch) +t _(ball flight))|  (6)

less than or equal to δ seconds, 0.15 seconds for example, then thevirtual bat can be assumed to have hit the virtual ball, and ananimation of the ball flight can then be rendered on the Web-enableddisplay 20 via the cloud-based graphics engine 125. However, if Δt>δseconds, the virtual bat is assumed to have missed the virtual ball andthe swing is deemed a strike.

Preferably, the sports motion analysis and synchronization uses asynchronized mobile device 10, a cloud-based (or otherwise networked)gaming server 120, and a Web-enabled display 20 each with a fidelity of0.1 seconds or less. Current web browsers have unreliable local clocktime stamps and Javascript calls to the internal clock typically do notpoll at exactly equal intervals. In a preferred embodiment, the NetworkTime Protocol (NTP) can be used to synchronize the computer systems overa packet-switched, variable-latency data network. We use the Java ScriptNTP client to acquire the time offsets of the clients (mobile device 10and display device 20) and the server (cloud based software engine).This sets the initial coordinated time based upon an accurate externalclock. We then schedule a Java Script callback using setInterval( ) atthe highest reliable granularity possible, which is web browserdependent. We do not assume that the callback is being called atreliable intervals, however, but instead use the call new Date().getTime( ) from within the callback and apply the offset to get theactual coordinated time, and then interpolate to find the actual time ofthe pitch, t_(pitch), and the virtual impact point, t_(impact point).These data are then used to calculate Eq. (6).

Hence our method is generalizable and extensible to the use case wherethe sports motion is impacting a moving virtual object, such as abaseball or tennis ball, and can be similarly applied to tennis,badminton, table tennis, racquet ball, hockey, basketball, Americanfootball, and all other similar sports where the virtual sports object(e.g., ball, puck, shuttlecock) is in motion and then struck, thrown, orcaught by the sports motion and the players virtual sports equipment.

Baseball instruction, especially for batting and pitching, can beincorporated into the gaming environment, following U.S. applicationSer. No. 13/659,774 to Jeffery et al., entitled METHOD TO PROVIDEDYNAMIC CUSTOMIZED SPORTS INSTRUCTION RESPONSIVE TO MOTION OF A MOBILEDEVICE, filed Oct. 24, 2012

Generalized Sports Motion Analysis

Our method of using data from multiple motion sensors of the mobiledevice to analyze a golf swing is generalizable to other types of sportsmotions.

FIGS. 11( a) to (c) shows example motion data of a tennis forehand, or aseated horizontal golf swing. In this example the swing path is in thehorizontal plane but with forearm rotation and wrist hinging aroundimpact. Hence, the motion signature is different from a standing golfswing and the impact point in FIG. 11( a) the pitch is now a zerocrossing of pitch data. The challenge is to detect the correct zerocrossing. In this example, the yaw is a local maximum near the impactpoint. Hence again using two types of rotational measurements (pitch andyaw), see FIGS. 11 (a) and (b), pitch and yaw, respectively, we can moreaccurately detect the impact point from data of a single sensor, in thiscase pitch. In the case of a tennis swing, the roll data at the impactpoint, see FIG. 11 (c), can be used to calculate the hook or slice spinimparted to the tennis ball.

Note that the calibration point need not be a specific setup positionwhere the mobile device 10 is held still for one second in the sameposition. For tennis and table tennis the calibration point may beobtained from any point where the player has his or her hands in a readyposition to play, and/or may be selected as an end point or calibrationpoint of a prior sports motion.

To illustrate preferred embodiments where the sports motion mayintersect with a moving virtual object and the release point and impactpoint is different from the calibration point, we provide examples forbaseball and bowling.

Baseball swing motion sensor data is illustrated in FIGS. 12( a) to (c).For a baseball swing the calibration point is a set-up position with themobile device 10 held in both hands out in front of the body, with thethumbs pointing so as to naturally line up the mobile device (virtualbat) with a ball on a virtual tee; the hands are perpendicular to theground. The data shown is from a professional athlete and illustratesthe essential features of an optimal baseball swing motion. For thebaseball sports motion, yaw FIG. 12 (a) is the key variable, since asthe “bat” is swung through the impact point with a virtual ball, theideal hand position is with the palms parallel to the ground, whichcauses a rapid change in yaw of the mobile device through impact. Theyaw at the calibration point was zero; hence the impact point is whenthe yaw crosses zero, see FIG. 13 (a), even though the mobile device isrotated ninety degrees relative to the calibration point. In an idealbaseball swing the roll of the bat occurs just after the impact pointsee, FIG. 13( b). In the event there is a roll maximum at the impactpoint, then the wrists have a tendency to lift the bat over the top ofthe ball, causing a ground or missed ball: this is the “swing bubble.”

The pitch and yaw of the mobile device 10 taken together provideinsights into the angle of the bat through the impact point. Forexample, the pitch data in FIG. 12( c) shows that the hands slopeddownward at the impact point, since the pitch is negative at the impactpoint and does not return to zero until after the impact point, andhence the bat would have contacted the virtual ball if it were thrownbelow the calibration point, that is, in the lower half of the strikezone.

As a last example, we consider the use case where the release point isdifferent from both the calibration point and the impact point. FIGS.13( a) to (c) illustrate the mobile device motion sensor data for abowling sports motion. In this example, the calibration point is thehand at rest, relaxed and fully extended at the player's side, with thepalm of the hand facing forward. The bowling motion is to first bringthe virtual bowling ball up to the chin, cradled in both hands, and thento swing down and forwards while taking a few steps. The pitch dataillustrates how the pitch of the mobile device 10 increases as themobile device 10 is brought up to the chin, where there is a localminimum as the player starts to step forward. Then, the pitch decreasesas the player swings down in the backswing motion, where there is a zeroof pitch corresponding to the initial calibration zero, and then themotion transitions to the final downswings to a second zero, which isthe release point of the virtual bowling ball.

Similar to the golf swing described previously, the velocity of thevirtual bowling ball can be calculated from Eq. (3) and the timedifference between 30 or 60 degree pitch points, similar to FIG. 8, orvia integrating Eq.'s (4). The rate of change of the roll data, thederivative of roll, through the release point is proportional to thespin rate imparted to the virtual bowling ball. Hence we can calculatethe velocity and spin of the virtual bowling ball at the release point.

Note in this example the release point is different in space from thecalibration point, and the impact point is further removed from therelease point. In this example, the impact point occurs in virtualspace. As described above, using a cloud-based gaming platform 100 thebowling ball can be displayed on a virtual bowling lane on an HTML5web-enabled display, such as a web TV, and the impact with the pinssimulated in time and space given the velocity and spin of the virtualbowling ball, and the length of the virtual bowling lane. Hence, theplayer executes the virtual bowling motion, and sees the virtual bowlingball go down the lane and hit the pins on the Web-enabled display, witha path and speed determined by the velocity and spin calculated from theswing signature of the mobile device and synchronized in time to appearlike a continuous motion.

While this invention has been described in conjunction with the variousexemplary embodiments outlined above, it is evident that manyalternatives, modifications and variations will be apparent to thoseskilled in the art. Accordingly, the exemplary embodiments of theinvention, as set forth above, are intended to be illustrative, notlimiting. Various changes may be made without departing from the spiritand scope of the invention.

What is claimed is:
 1. A gaming system, comprising: a gaming serverconfigured to manage at least one game, wherein (a) a first connectionis established between a first device and the gaming server, the firstdevice having first motion sensors; (b) a second connection isestablished between a second device and the gaming server; (c) a thirdconnection is established between a third device and the gaming server,the third device having second motion sensors; (d) at the gaming server,via the first connection, first device game motion data is received fromthe first device, the first device game motion data determined using thefirst motion sensors, responsive to the first device being moved by afirst player during a game; (e) at the second device, first imagecontent is displayed related to the game, the first image contentrendered at least in part based on the received first device game motiondata; (f) at the gaming server, via the third connection, third devicegame motion data is received from the third device, the third devicegame motion data determined using the second motion sensors, responsiveto the third device being moved by a second player during the game; and(g) at the second device related to the game, second image content isdisplayed, the second image content rendered at least in part based onthe received third device game motion data.
 2. The gaming system ofclaim 1, wherein the second device is a web-enabled display.
 3. Thegaming system of claim 1, wherein the first connection and the secondconnection are separate Internet connections.
 4. The gaming system ofclaim 1, wherein the first motion sensors include a gyroscope and anaccelerometer.
 5. The gaming system of claim 1, wherein the first deviceanalyzes raw motion data obtained from the gyroscope and theaccelerometer to determine the first game motion data.
 6. The gamingsystem of claim 1, wherein the first device game motion data includesswing speed and roll angle.
 7. The gaming system of claim 6, wherein thefirst device game motion data includes forearm rotation rate, wristhinge, and swing path.
 8. The gaming system of claim 1, wherein thefirst device and the second device are connected via a fourth connectionon a local area network (LAN), and the third device and the fourthdevice are connected via a fifth connection on the LAN.
 9. A gamingsystem, comprising; a gaming server configured to manage at least onegame, wherein (a) a first connection is established between a firstdevice and the gaming server, the first device having first motionsensors; (b) a second connection is established between a second deviceand the gaming server; (c) at the gaming server, via the firstconnection, first device game motion data is received from the firstdevice, the first device game motion data determined using the firstmotion sensors, responsive to the first device being moved by a firstplayer during a game; (d) at the second device, first image content isdisplayed related to the game, the first image content rendered at leastin part based on the received first device game motion data.
 10. Thegaming system of claim 9, wherein the first device game motion datarelates to at least one sports motion.
 11. The gaming system of claim 9,wherein the first device game motion data includes a starting pointdetermined by the first device being held still.
 12. The gaming systemof claim 9, wherein the second device is a web-enabled display.
 13. Thegaming system of claim 9, wherein the first connection and the secondconnection are separate Internet connections.
 14. The gaming system ofclaim 9, wherein the first motion sensors include a gyroscope and anaccelerometer.
 15. The gaming system of claim 9, wherein the firstdevice analyzes raw motion data obtained from the gyroscope and theaccelerometer to determine the first device game motion data.
 16. Thegaming system of claim 9, wherein the first device game motion dataincludes swing speed and roll angle.
 17. The gaming system of claim 16,wherein the first device game motion data includes forearm rotationrate, wrist hinge, and swing path.
 18. The gaming system of claim 9,wherein the rendered first image content is rendered by selecting amonga plurality of image content.
 19. The gaming system of claim 18, whereinthe plurality of image content includes image content predicted toprobably occur.
 20. The gaming system of claim 9, wherein the renderedfirst image content relates to an impact or release point determinedusing the first device motion data including both pitch and yaw motiondata.
 21. The method of claim 9, further comprising: (e) establishing annth connection between an nth device and the gaming server, the nthdevice having (n−1)th motion sensors; (f) establishing an (n+1)thconnection between an (n+1)th device and the gaming server; (g)receiving at the gaming server, via the nth connection, nth device gamemotion data from the nth device, the nth device game motion datadetermined using the (n−1)th motion sensors, responsive to the nthdevice being moved during the game; and (h) displaying image content atthe (n−1)th device and the (n+1)th device related to the game, the imagecontent rendered at least in part based on the nth device game motiondata; (i) wherein n is an integer, 3≦n.
 22. A gaming system, comprising;a gaming server configured to manage at least one game, wherein (a) afirst connection is established between a first device and the gamingserver, the first device having first motion sensors; (b) a secondconnection is established between a second device and the gaming server;(c) a third connection is established between a third device and thegaming server, the third device having second motion sensors; (d) at thegaming server, via the first connection, first device game motion datais received from the first device, the first device game motion datadetermined using the first motion sensors, responsive to the firstdevice being moved by a first player during a game; (e) at the seconddevice, first image content is displayed related to the game, the firstimage content rendered at least in part based on the received firstdevice game motion data; (f) at the gaming server, via the thirdconnection, third device game motion data is received from the thirddevice, the third device game motion data determined using the secondmotion sensors, responsive to the third device being moved by a secondplayer during the game; and (g) at the second device related to thegame, second image content is displayed, the second image contentrendered at least in part based on the received third device game motiondata.
 23. The gaming system of claim 22, further including wherein thefirst device game motion data includes a starting point.